Hackers Underworld 2: Forbidden Knowledge/Hackers Underworld 2: Forbidden Knowledge.iso/VIRUS/EVAL.TXT

Text File | 1989-10-21 | 26KB | 499 lines

                    Anti-Viral Product Evaluation
                          May 5, 1989

     This evaluation paper has been written by Jim Goodwin, Lynn
Marsh and Tim Sankary.  It is copyrighted, 1989, and is intended
for circulation among fellow members of the virus research
community who use IBM PCs or compatibles.  We do not consider it
complete, since we did not evaluate every available product, and
it is not intended as a public guide to selecting antiviral
programs.  We hope, however, that it will prove useful to other
members of the community who work with live viruses and need
ongoing protection for their systems.  This document may be
freely copied and distributed providing the disclaimer and
copyright are kept intact, and no changes, additions or deletions
are made to the text.
     We would like to acknowledge the ample research data
provided by Jim Bates and Rusty Davis in England, Ivan Grebert of
Acal Corporation in Paris, Colin Haynes of the International
Computer Virus Institute, and the many volunteer researchers from
the Silicon Valley area that contributed so much to our efforts.
We would also like to acknowledge the HomeBase users group for
providing their detailed log of infection occurrences and other
epidemiological data.


The Need for a Reasonable Evaluation:
     In the April issue of PC Magazine you will find a review of
11 antiviral products.  The review, while well intentioned,
tested products against only two viruses (plus one simulated
virus that was developed by the magazine).  None of the viruses
were boot sector infectors (viruses which attach to the boot
sector) and none were among the most common viruses.  Since the
vast majority of virus infections are boot sector infections, and
since most viruses are much more difficult to detect than the two
chosen, the results of the review were next to meaningless.  The
PC Magazine review was similar to many others published in the
past year.  It was performed without adequate access to the
viruses actually causing problems in the user community.
     A second problem with these reviews, is that many of the
reviewers have had limited experience with the broad range of
infections that have occurred within the past 18 months.  They
base evaluations on assumptions that do not hold for the real
world.  This is not necessarily the fault of the reviewers.
Viruses are a new phenomenon and few people have dedicated their
time and resources to a long term study.  A reviewer who has had
experience with only one or two viruses might naturally draw
incorrect conclusions about "generic" virus issues.
     For example, a number of viruses infect programs using
common DOS calls (interrupt 21 or other interrupt call).  This
type of infection can be easily detected and prevented.  An
entire class of products, called Filters, has grown up around the
assumption that virus infections can be prevented by redirecting
certain interrupts and intercepting the infection replication
process. It works for a few viruses.  The vast majority of
infections, though, are caused by viruses that use non-standard
I/O, and these infections cannot be prevented through interrupt
re-vectoring techniques.  Thus, filter type products - included
among them are C-4 and Flu-Shot+ - are virtually useless against
most viruses.  Yet many reviewers, and some product developers,
still believe that viruses can be stopped through re-directing
system interrupts.

The criteria:
     A lot of time and effort has gone into the various checksum,
encryption, logging and chaining algorithms proposed as safe
techniques for detecting viruses.  And much discussion and
argumentation has gone one regarding the various merits of high
security algorithms.  Yet, every generic application infector
that we have seen to date could have been detected by merely
checking to see if the SIZE of the file had changed.  Developing
such a virus detector requires less than an hour of programming
time and is as effective as available products costing hundreds
of dollars.   We're not suggesting that size checking should be
the criteria for detecting viruses (we know better), we are
merely pointing out the vast gulf between theory and current
reality.  We understand that viruses of today may not reflect the
situation two years from now, and we also understand that current
boot sector viruses and certain operating system viruses pose a
special case to our size example, but the first step in solving
any problem must be a solid understanding of the current state of
the problem.  And the current problem is in a different world
from the theoretical solutions proposed for it.
     An astute reader might ask at this point why we would be
concerned if the proposed solutions to viruses were overkill.
Isn't it better, you might think, to include as much protection
as is available, to get as close to 100% security as possible?
We think not.  Beta testing of virus products in many
corporations and our own experience with these products over the
past year has shown that, beyond a certain point of
reasonableness, increased security functions begin to hinder the
computing process.  Either increases in required run time, or
user constraints or annoying additions to the system make the
products so cumbersome to use that the user ultimately discards
them.  Alternately, false alarms and questionable product
conditions desensitize the user, and thus real virus alarms, when
they occur, are disregarded.
     Again, we are not saying that sound security principles
should not be included in a given product.  We are only
suggesting that the search for the 100% solution must have its
limits.  The theoretical discussions about batch file viruses,
viruses that can imbed themselves within a program without
changing initial branch addresses, and viruses that can infect
without making any modifications to a program are interesting and
entertaining.  But if you are selecting a product based on the
ability to detect such viruses, then you will be disappointed.
     In general then, our criteria for evaluating antiviral
programs are:

     1.   The program's effectiveness against existing viruses.
          There are anywhere from two dozen to over 50 different
          PC viruses (depending on how you classify them) that
          can infect your system today.  If the product cannot
          detect these viruses, then it certainly cannot detect
          tomorrow's viruses.  We rated this criteria the
          highest.

     2.   The techniques used by the program to anticipate new
          viruses.  We have to admit to some subjectivity here.
          No-one really knows what virus may pop up tomorrow, but
          reasonable people can make reasonable guesses (Tim
          Sankary is the only member of this review team who
          admits to being unreasonable).  We do expect to see
          viruses in the next few years that can imbed themselves
          inside a generic COM or EXE program without changing
          its size.  We anticipate system infectors and other
          program-specific viruses that can imbed themselves AND
          not change initial branch instructions.  (We feel these
          viruses, however, will be limited to common programs
          such as IBMBIO, IBMSYS, COMMAND.COM etc.).  We
          anticipate viruses that will encrypt themselves in such
          a way that every infection will be different (1704
          nearly achieves that now).  We anticipate boot sector
          viruses that will not need to save and execute the
          original boot sector.  We also expect viruses that will
          entirely replace system modules, such as the command
          interpreter.

     3.   The usability of the software.  This is the most
          subjective criteria and we accordingly weighted it the
          least.  We decided, however, that if we felt like
          screaming, smashing the monitor or savagely beating the
          family pets while trying to install or use t